Conventional integrated circuit (i.e., chip) input/output (IO) controllers use multi-processor designs that include an input/output processor (IOP) and one or more context manager (CTX) processors. The context managers include the processor and all of the dedicated hardware components of the bus (or protocol) channel. The IOP and each of the CTX processors include dedicated sets of firmware. The IOP (i) receives Message Passing Technology (MPT) request messages from a host operating system (OS) device driver, (ii) performs some processing on the messages, and (iii) transmits the messages to the CTX processors. The context managers handle the dedicated bus protocol (i.e., SCSI, Fibre Channel, Serial ATA, etc.) of the chip. In a dual channel (i.e., dual bus) design, there is a context manager dedicated to each channel.
The OS and the IOP communicate via a set of dedicated system request and system reply first in, first out registers (FIFOs) that are included in the IO controller. In a dual channel controller there is a dedicated set of the system request FIFOs and system reply FIFOs for each peripheral computer interconnect (i.e., PCI, PCI-X, PCI-X DDR, etc.) function. Each PCI function has a one to one relation with a CTX channel (i.e., PCI function 0 is dedicated to channel 0 and PCI function 1 is dedicated to channel 1). The IOP receives pointers to messages that are posted by the OS on the system request FIFOs and presents the pointers to the corresponding CTX processor.
The small computer systems interface (SCSI) bus protocol was developed as a simple and efficient method of connecting one or more peripherals to a personal computer (PC) and/or a server computer. An IO controller that implements the SCSI protocol can set a SCSI parallel interface SPI L_Q information unit type field to multiple (or multi-) command (i.e., multiple commands or multiple IO requests can be sent to the respective device in the same connection). The American National Standard of Accredited Standards Committee INCITS, Information technology SCSI Parallel Interface-4 (SPI-4), document T10, Project 1365D, Revision 9, 30-Jan. -2002, which is incorporated herein by reference in its entirety, provides the relevant details of the multi-command mode.
Each of the context managers has a dedicated set of inter-processor (IP) queues that are used for communication between the context manager and the IOP. The context managers do not communicate between each other, but only communicate with the IOP. When the IOP has completed processing a request message from the OS, the IOP sends the message to the CTX by posting the message on the inter-processor IO request queue. When the CTX has completed processing the message (or IO), the CTX replies back to the IOP with the status of the IO via the inter-processor IO completion queue. The IOP (i) receives replies from each of the context managers via the IO completion queues, (ii) performs some cleanup, and (iii) sends the status back to the OS via the system reply FIFO.
Referring to FIG. 1, a detailed block diagram illustrating a conventional OS driver and IO controller circuit 10 is shown. The circuit 10 includes an OS driver 12, a PCI bus 14, and an IO controller 16. The host OS device driver 12 is coupled to the IO controller 16 via the PCI bus 14. The OS driver 12 includes a first plurality of message frames 20a-20n, a second plurality of message frames 22a-22n, a first host interface 24, and a second host interface 26. The controller 16 includes a first plurality of PCI function registers 30a-30n, a second plurality of PCI function registers 32a-32n, a request FIFO 34, a message assist engine 36, a free FIFO 38, a plurality of message frames 40a-40n, an IOP 42, a first inter-processor queue that includes an IO request register 44a and an IO completion register 46a, a second IP queue that includes an IO request register 44b and an IO completion register 46b, a first CTX manager 48a, a second CTX manager 48b, a first SCSI core 50a, a second SCSI core 50b, and a reply FIFO 52.
The following steps describe the flow of an IO message between the OS device driver 12, the IOP 40 and the CTX managers 48:
Step A
The host OS driver 12 generates a SCSI (or other appropriate protocol) IO message in the host address space 20.
Step B
The host OS driver 12 posts a system message frame address (SMFA) to the PCI function request register 30 via the host interface 24 and the bus 14.
Step C
The PCI function request register 30 presents the SMFA to the request FIFO 34.
Step D
The request FIFO 34 presents the SMFA to the message assist engine 36.
Step E
The message assist engine 36 waits for a local message frame address (LMFA) in the local message frame 40 to become free.
Step F
The message assist engine 36 presents (i.e., direct memory addresses) the system message frame SMFA to the local message frame 40.
Step G
The message assist engine 36 writes the LMFA to the request FIFO 34.
Step H
The IOP 42 polls the interrupt status register for the request queue (i.e., the free FIFO 38) for a new request and receives the LMFA.
Step I
The IOP 42 examines the message header function to determine the type of message addressed by the LFMA. When the message is an SCSI IO request and the message is tagged as a request, the message is assigned a Qtag.
Step J
The IOP 42 posts a message index (MID) on the inter-processor IO request queue 44.
Step K
The CTX manager 48 polls an internal interrupt status register (i.e., the IO request queue 44) for a new request (i.e., MID).
Step L
The CTX manager 48 writes the message index MID into a context lookup table and writes a copy of the message to the SCSI core IO bucket 50.
Step M
The CTX manager 48 completes the IO by posting the unmodified MID on the IO completion queue 46.
Step N
When an error in the IO flow is indicated, the CTX manager 48 sets an exception bit in the MID indicating the message frame 40 has error status data. The IOP 42 polls the IO completion queue 46 interrupt status register and receives the MID.
Step O
When successful IO flow is indicated, the IOP 42 posts an unmodified message context to the reply FIFO 52 using a function bit in the MID to determine which function to implement.
When an error in the IO flow has been indicated, The IOP 42 presents (i.e., direct memory accesses) a reply frame to a host reply buffer and posts a ready for data signal (e.g., RFD) to the reply FIFO 52.
Step P
The IOP 42 frees the LMFA in the free FIFO 38.
Step Q
The host OS driver 12 receives an interrupt message (INTERRUPT) for a reply.
The IOP 42 performs an intermediary function between the OS driver 12 and the CTX managers 48a and 48b. During a normal mode of operation, the IOP 42 (i) continually receives IO requests from the OS 12, (ii) presents the IO requests to the CTX managers 48, (iii) receives IO completions from the CTX managers 48, and (iv) presents the IO completions to the OS 12.
When the IOP 42 firmware receives an IO request (i.e., a SMFA that corresponds to an IO request) from the operating system driver 12, the IOP 42 sorts the requests by device identification (ID) (i.e., a respective SCSI core 50) and posts the IO requests to the respective IP queue 44 (i.e., as a respective message index signal MID). A particular IP queue 44 only receives IO requests for a given device ID. The system 10 is configured having a dedicated (or respective) IP queue 44 per device ID.
Conventional approaches to handling IO requests include checking the next IO request to determine if the IO request accesses the same device ID as the current IO request. Conventional approaches check the IO requests in the order that the IO requests have been sent to the controller 16 by the host operating system 12. However, many conventional operating systems 10 do not send IO requests ordered by the respective devices. Furthermore, the conventional operating systems 10 that send IO requests ordered by devices are not maximized since the SPI L_Q command was developed after most operating system device drivers were developed.
It would be desirable to have a method and/or apparatus that (i) sorts IO requests by device ID and sends SPI L_Q information unit multi-commands to the respective devices, (ii) reduces and/or eliminates performance penalties and/or extra processing overhead in the IOP and context manager firmware on a SCSI MPT based controller, and/or (iii) maximizes the SPI L_Q command feature while not hindering the operation and/or performance of the operating system driver.